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DETAILED ACTION 

/ Response to Amendment 

/ \ 

1 . . This action isVesponsive to the Amendment filed on 1 8 December 2002. Claims 
1-31 are pending. Claims 1, 16, 20 and 24 have been amended. 

2. The amendments filed are sufficient to overcome the drawing and specification 
objections and prior 35 U.S.C. 112 first paragraph rejections of claims 11-15, 19-23 and 
26-31 . However they are not sufficient to overcome the objections to claims 21 or 31 . 



Claim Rejections - 35 USC § 102 

3. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent. 

Claims 1-3, 5, 6, 18 and 19 are rejected under 35 U.S.C. 102(a) as being 
anticipated by Guinther et al. (U.S. Patent No. 6,016,466). 

Referring to claim 1 , Guinther et al. discloses a computing system having a mass 
storage device (see Guinther et al., col. 3 line 66 - col. 4 line 9) and a system timer (see 
Guinther et al., col. 22 lines 47-49) for obtaining benchmark timing for a portion of an 
application program execution (see Guinther et al., col. 2 lines 23-31), the application 
program having permanently inserted performance markers (see Guinther, column 22 
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lines 32-35), the computing system comprising: having a mass storage system (see 
Guinther et al., col. 3 line 66 - col. 4 line 9), an init module for determining if the 
timestamp data is to be collected during the operation of the application program (see 
Guinther et al., col. 18 line 64 - col. 19 line 2), a performance marker module for 
obtaining and storing the timestamp data for later retrieval (see Guinther et al., col. 4 
lines 63-67) at predefined points corresponding to the permanently inserted 
performance markers (see Guinther, column 22 lines 32-35), an uninit module for 
formatting and storing the obtained timestamp data into a data file within the mass 
storage device that permits retrieval after the termination of the application program 
(see Guinther et al., col. 7 line 58 - col. 8 line 20), and a performance benchmark data 
post processing module for determining the benchmark timing from two or more 
timestamp data entries (see Guinther et al., col. 22 lines 34-41), wherein an init module 
is executed before timestamp data is collected (see Guinther et al., col. 18 line 64 - col. 
19 line 2), a performance marker module executed each time benchmark timestamp 
data and overhead timestamp data is to be collected (see Guinther et al., col. 2 lined 
23-31), an uninit module is executed after all timestamp data desired has been collected 
(see Guinther et al., coL 19 line 9-17), and a performance benchmark data post 
processing module which determines the benchmark timing from timestamp entries (see 
Guinther et a!., coL 19 lines 13-17) stored within the data file (see Guinther et al., col. 20 
line 64 - col. 21 line 2). 



m 
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Referring to claim 2, Guinther et al. discloses an init module for determining if the 
timestamp data is to be collected (see Guinther et al., col. 18 line 64 col. 19 line 2). 

Referring to claim 3, Guinther et al. discloses an init module for determining if the 
timestamp data is to be collected by checking for the existence of an identification key 
within a system registry (see Guinther et al., col. 18 line 64 - col. 19 line 2), where the 
identification key uniquely identifies the processing modules (see Guinther et al., col. 19 
lines 13-17) to be used to collect, format, and store the run-time internal state data to be 
collected (see Guinther et a!., col. 18 line 15-24). The examiner interprets the statement 
"profiling does not occur if the DLL is not present" (see Guinther et al., col. 19 lines 1-2) 
as disclosed by Guinther et al. to read on the claim limitation "checking for the existence 
of an identification key within a system registry" (see page 16 lines 13-16). 

Referring to claim 4, Guinther et al. teaches the timestamp data comprises a 
timer count value obtained from the system timer (see Guinther et al., col. 22 lines 47- 
49). 

Referring to claim 5, Guinther et al. discloses a performance marker module 
which collects timestamp data only if the init module has determined that the timestamp 
data is to be collected (see Guinther et al., col. 18 line 64 - col. 19 line 2). 



Application/Control Number: 09/606,925 Page 5 

Art Unit: 2857 

Referring to claim 6 Guinther et al. discloses a performance marker module 
which generates a data record containing a benchmark timestamp data value each time 
the performance marker module is executed (see Guinther et al., col. 20 lines 37-40). 

Referring to claims 13 and 18, Guinther et al. discloses encoding a computer 
program of instructions for executing a computer process for obtaining run-time internal 
state data within an application program (see Guinther et al., col. 18 lines 15-24), having 
the steps: permanently inserting one or more code markers into the application program 
at locations within the application program corresponding to the point at which 
benchmark timing data is desired (see Guinther et al., col. 22 lines 24-35), determining 
if benchmark timing data is to be collected at each code marker by checking for the 
existence of processing modules identified by an identification key within a system 
registry (see Guinther et al., col. 18 line 64 - col. 19 line 2), if benchmark timing data is 
to be collected at each code marker (see Guinther et a!., Figure 15), generate a 
benchmark data record containing the collected benchmark timing data each time the 
code markers are reached (see Guinther et al., col. 20 lines 37-40), store the 
benchmark data records within a data memory block (see Guinther et al., col. 7 lines 60- 
63) within the processing modules identified by the identification key within the system 
registry (see Guinther et al., col. 18 line 64 - col. 19 line 2), retrieve the benchmark data 
records from the data memory block for transfer to a mass storage device once all of 
the run-time internal state data has been collected (see Guinther et al., col. 19 lines 13- 
17), and process the benchmark data records stored within the mass storage device to 
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determine the benchmark timing defined between two benchmark data records (see 
Guinther et al., col. 22 lines 36-41). 

Referring to claim 19, Guinther et al. discloses determining if the timestamp data 
is to be collected by checking for the existence of an identification key within a system 
registry (see Guinther et aL, col. 18 line 64 - col. 19 line 2), where the identification key 
uniquely identifies the processing modules to be used (see Guinther et al., col. 19 lines 
13-17) to collect, format, and store the run-time internal state data to be collected (see 
Guinther et al., col. 18 line 15-24). The examiner interprets the statement "profiling 
does not occur if the DLL is not present" (see Guinther et al., col. 19 lines 1-2) as 
disclosed by Guinther et al. to be synonymous with the claimed phrase "checking for the 
existence of an identification key within a system registry" (see page 16 lines 13-16). 

Referring to claim 20, Guinther et al. discloses determining that benchmark 
timing data is to be collected by checking for the existence of processing modules 
identified by the identification key within the system registry (see Guinther et al., col. 18 
In 64 -col. 19 line 2). 

Referring to claim 21 , Guinther et al. discloses a data memory block which is in 
the processing modules identified by the identification key within the system registry 
(see Guinther et al., col. 19 lines 17-21). 
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Referring to claim 22, Guinther et al. discloses benchmark timing determined 
from the difference between two benchmark timestamp data entries stored within the 
data file (see Guinther et al., col. 22 lines 36-41). 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

Claims 7-12 and 23-26 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Guinther et al. (U.S. Patent No. 6,016,466) in view of Levine et aL 
(U.S. Patent No. 6,349,406). 

Referring to claim 7, Guinther et al. teaches all but a benchmark data record - 
further containing an overhead timestamp data value each time the performance marker 
module is executed. Levine et al. further teaches a current event time (i.e. overhead 
timestamp data) associated with a current trace record (see Levine et al., col. 22 lines 
27-29). The examiner interprets the terms "current trace record" (see Levine et a!., col. 
22 line 29) and "current event time" (see Levine et al., col. 22 line 28) to read on the 
claimed terms "benchmark data record" and "overhead timestamp data value", 
respectively (see Levine et al., Figure 20B). It would have been obvious to one of 
ordinary skill in the art at the time the invention was made to modify Guinther et al. to 
include the teachings of Levine et al., because the overhead timestamp data enables 
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the skilled artisan to calculate the total overhead value (see Levine et al., col. 22 lines 
29-32). 

Referring to claim 8, Guinther et al. further discloses a performance marker 
module which stores the benchmark data records within a data memory block (see 
Guinther et al., col. 7 lines 60-63) within the processing modules identified by an 
identification key within the system registry (see Guinther et al., col. 18 line 64 - col. 19 
line 2). 

Referring to claim 9, Guinther et al. further discloses a uninit module which 
retrieves the data records from the data memory block for transfer to the data file (see 
Guinther et al., col. 20 lines 37-40) on the mass storage device (see Guinther et al., col. 
3 line 66 -col. 4 line 5), 

Referring to claim 10, Guinther et al. further discloses determining the 
benchmark timing from the difference between two benchmark timestamp data enthes 
(see Guinther et al., col. 22 lines 36-41) stored within the data file (i.e. thread database 
412). 

Referring to claims 1 1 and 23, Guinther et al. does not teach determining 
benchmark timing by subtracting an estimate for the total overhead processing from the 
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difference between two benchmark timestamp data entries stored within the raw data 
table. 

Levine et al. teaches determining benchmark timing by subtracting an estimate 
for the total overhead processing from the difference between two benchmark 
timestamp data entries stored within the raw data table (see Levine et al., col. 24 lines 
36-39). 

It would have been obvious at the time the invention was made to one of ordinary 
skill in the art to modify Guinther et al. to include the teachings of Levine et al. because 
the artisan needs overhead timestamp values to adjust the recorded time values for an 
accurate measurement of the time (see Levine et al., col. 22 lines 51-55). 

Referring to claims 12 and 24, Guinther et al. teaches all but the estimate for the 
total overhead processing as being determined by totaling the difference between an 
overhead timestamp value and a benchmark timestamp value for all code markers 
between the two benchmark timestamp entries used to determine the benchmark 
timing. 

Levine et al. teaches determining the estimate for the total overhead processing 
(see Levine et al., Figure 23B) by totaling the difference between an overhead 
timestamp value (i.e. "Call From7Entry Overhead to Routine A 2356) and a benchmark 
timestamp value for all code markers between the two benchmark timestamp entries 
(i.e. base time for routine A 2352, 2372) used to determine the benchmark timing. 

It would have been obvious at the time the invention was made to one of ordinary 
skill in the art to modify Guinther et al. to include the teachings of Levine et al. because 
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determining the overhead time enables the artisan to modify the recorded time values 
for an accurate time measurement (see Levine et al., col. 22 lines 51-55). 

Referring to claim 25, Guinther et al. teaches all but a benchmark timestamp 
value obtained from a system timer immediately after a code marker is reached, and an 
overhead timestamp value obtained from the system timer immediately before 
processing returns to the application program from performance marker processing. 

Levine et al. teaches obtaining benchmark timestamp value from a system timer 
immediately after a code marker is reached, and obtaining an overhead timestamp 
value from the system timer immediately before the processing returns to the 
application program from performance marker processing (see Levine et al., Figure 
20A-B). 

It would have been obvious at the time the invention was made to one of ordinary 
skill in the art to modify Guinther et al. to include the teachings of Levine et al. because 
overhead timestamp values can be used to compensate for the overtime (see Levine et 
al., col. 22 lines 51-55). 

Referring to claim 26, Guinther et al. further teaches encoded instructions used 
to implement the computer process (see Guinther et al., col. 18 lines 64-67). 
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5. . Claim 27 is rejected under 35 U.S.C. 103(a) as being unpatentable over Guinther 
et al. (U.S. Patent No. 6,016,466) (hereinafter Guinther) in view of Wygodny et al. (U.S. 
Patent No. 6,282,701) (hereinafter Wygodny). 

Referring to claim 27, Guinther teaches all the features of the claimed invention 
except for a propagated signal on a carrier detectable by a computing system and 
encoding a computer program of instructions for executing the computer process. 

Wygodny teaches a propagated signal on a carrier detectable by a computing 
system and encoding a computer program of instructions for executing the computer 
process (see Wygodny, column 5 lines 14-23). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Guinther to include the teachings of Wygodny because 
having a propagated signal on a carrier detectable by a computing system, and 
encoding a computer program allows the skilled artisan to analyze the program 
remotely without exposing the source code to the customer (see Wygodny, column 3 
lines 40-44). 



Double Patenting 

6. The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. See In re Goodman, 1 1 
F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Long!, 759 F.2d 887, 225 
USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 
1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970);and, In re Thorington, 
418 F.2d 528, 163 USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be 
used to overcome an actual or provisional rejection based on a nonstatutory double 
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patenting ground provided the conflicting application or patent is shown to be commonly 
owned with this application. See 37 CFR 1 .130(b). 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 

Claim 1 is provisionally rejected under the judicially created doctrine of 
obviousness-type double patenting as being unpatentable over claims 1 and 2 of 
copending Application No. 09/606896 ("the '896 application"). 

Although the conflicting claims are not identical, they are not patentably distinct 
from each other. 

Claim 1 of the instant application recites: a computing system having a mass 
storage device and a system timer for obtaining benchmark timing for a portion of an 
application program execution, having a mass storage system, an init module for 
determining if the timestamp data is to be collected during the operation of the 
application program, a performance marker module for obtaining and storing the ■ 
timestamp data for later retrieval, an uninit module for formatting and storing the 
obtained timestamp data into a data file within the mass storage device that permits 
retrieval after the termination of the application program, and a performance benchmark 
data post processing module for determining the benchmark timing from two or more 
timestamp data entries, wherein an init module is executed before timestamp data is 
collected, a performance marker module executed each time benchmark timestamp 
data and overhead timestamp data is to be collected, an uninit module is executed after 
all timestamp data desired has been collected, and a performance benchmark data post 
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processing module which determines the benchmark timing from timestamp entries 
stored within the data file. 

Claims 1 and 2 of the '896 application recite every limitation of the application 
claim, the only differences being that (a) the instant application stores the collected data 
in a "data file" whereas the '896 application stores its data in a "Raw Data Table", and 
(b) the instant application discloses that "the performance marker module is executed 
each time benchmark timestamp data and overhead timestamp data is to be collected", 
whereas the '896 application discloses that the performance marker module "is 
executed at predefined points" to collect timestamp data. 

There is no functional difference between storing the data in a "data file", as 
claimed in the instant application, or storing the data in a "Raw Data Table" as claimed 
in the '896 application. Similarly, there is no functional difference between executing 
the performance module marker "each time benchmark timestamp data and overhead 
timestamp data is to be collected" (instant application) and executing the performance 
marker "at predefined points" ('896 application), as the "predefined points" ('896 
application) would be located where "timestamp data is to be collected" (instant 
application). 

Claim 2, 3 and 5 are provisionally rejected under the judicially created doctrine of 
obviousness-type double patenting as being unpatentable over claims 3, 4, and 5 of 
copending Application No. 09/606896 ("the '896 application"), respectively. 
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Although the conflicting claims are not identical, they are not patentably distinct 
from each other. 

Referring to claim 2, both the instant application (claim 2) and the '896 
application (claim 3) disclose an init module for determining if the timestamp data is to 
be collected. 

Referring to claim 3, both the instant application (claim 3) and the '896 
application (claim 4) disclose an init module for determining if the timestamp data is to 
be collected by checking for the existence of an identification key within a system 
registry, where the identification key uniquely identifies the processing modules to be 
used to collect, format, and store the run-time internal state data to be collected. 

Referring to claim 5, both the instant application (claim 5) and the '896 
application (claim 5), disclose a performance marker module which collects timestamp 
data only if the init module has determined that the timestamp data is to be collected. 

Claims 2, 3 and 5 are dependent on claim 1, and therefore the same reasons for 
obviousness apply. There is no functional difference between storing the data in a "data 
file" (instant application) or storing the data in a "Raw Data Table" ('896 application). 

This is a provisional obviousness-type double patenting rejection because the 
conflicting claims have not in fact been patented. 

Response to Arguments 

7. Applicant's arguments filed 18 December 2002 have been fully considered but 
they are not persuasive. 
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Applicant argues that Guinther does not teach permanently adding a 
performance marker to the code to obtain timestamp data. However, it is the 
Examiner's position that Guinther does suggest this limitation. Guinther teaches 
inserting monitoring instructions into the code to collect timestamp data (see Guinther, 
column 22 lines, 24-41). Guinther also teaches that this code may be entered in a 
variety of conventional ways, including, "manually inserting the data" (see Guinther, 
column 22 lines 32-35). Manually inserting the monitoring data into the application code 
suggests that this code modification is permanent. Further, Guinther does not suggest 
removing the code after timing data has been gathered. 

Applicant further argues that Levine does not teach inserting markers into the 
code. However, the Examiner uses Guinther to reject this limitation of inserting markers 
into the source code to collect overhead data. Levine is used to reject the limitations 
pertaining to collecting benchmark and overhead timestamp data. 

Conclusion 

8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Mary Kate B Baran whose telephone number is (703) 
305-4474. The examiner can normally be reached on Monday - Friday from 8:00 am to 
5:00 pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor. Marc S Hoff can be reached on (703) 308-1677. The fax phone numbers for 
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th§ organization where tlnis application or proceeding is assigned are (703) 872-9318 for 
regular communications and (703) 872-9319 for After Final communications. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the receptionist whose telephone number is (703) 308- 



1782. 



MKB 

March 5, 2003 
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